The IP multimedia subsystem (IMS) is a subsystem overlaid above an existing packet switched (PS) domain in a Wideband Code Division Multiple Access (WCDMA) network added in the 3rd Generation Partnership Project (3GPP) R5, and uses the PS domain as the bearer channel for the upper layer control signaling and media transmission. The Session Initiation Protocol (SIP) is introduced as the service control protocol. Taking advantage of the features that the SIP is simple, easy to be extended, and convenient for media combination, the IMS provides various multimedia services through the separation of the service control and the bearer control. The functional entities in the IMS include a call session control function (CSCF) configured to perform user registration control and service control, a home subscriber server (HSS) configured to collectively manage user subscription data, an application server (AS) configured to provide various service logic control functions, etc.
FIG. 1 is a schematic view of the network structure of the IMS network in the prior art. In FIG. 1, AS is an application server, HSS is a home subscriber server, I-CSCF is an interrogating CSCF, P-CSCF is a proxy-CSCF, S-CSCF is a serving CSCF, and UE is user equipment. As shown in FIG. 1, a service process of a user is as follows: after the UE is started, the UE initiates a registration process to the IMS network; after receiving a registration request from the user, the IMS network saves information such as registration data and registration state of the user in the corresponding network elements, for example, the P-CSCF, S-CSCF, AS, and HSS all store the registration information of the user. The UE carries a registration period parameter in a registration message, and after the UE is registered successfully, the UE periodically initiates a re-registration process to the IMS network to update the registration data and registration state of the user. Only the user in the registered state on the corresponding network element in the IMS network can perform the corresponding user service, such as, initiate a call as a calling party or receive a call as a called party.
FIG. 2 is a flow chart of a service performing process of a user in the IMS network described in the 3GPP standards in the prior art. As shown in FIG. 2, the process includes the following steps.
In Step 201, after the UE is started, the UE sends a Register message to the P-CSCF.
In Step 202, after storing relevant data of the user locally, the P-CSCF forwards the Register message to the I-CSCF in a home domain of the user.
In Step 203, the I-CSCF sends a User-Authorization-Request (UAR) to the HSS, and queries the S-CSCF that can provide the service to the user.
In Step 204, the HSS returns a User-Authorization-Answer (UAA) carrying the S-CSCF that can provide the service to the user to the I-CSCF.
In Step 205, the I-CSCF forwards the Register message to the selected S-CSCF.
In Step 206, the S-CSCF sends a Server-Assignment-Request (SAR) to the HSS, and requests subscription data of the user from the HSS.
In Step 207, the HSS returns a Server-Assignment-Answer (SAA) carrying the subscription data of the user to the S-CSCF.
In Step 208, the S-CSCF initiates a third-party registration to the corresponding AS according to the subscription data of the user, and stores relevant data of the user locally.
In Step 209, the AS responds with a registration success response.
In Step 210, the S-CSCF responds with a registration success response.
In Step 211, the I-CSCF responds with a registration success response.
In Step 212, the P-CSCF responds with a registration success response.
In Step 213, after the user is registered successfully, the user may start to perform the corresponding service process.
In Step 214, after the UE registration period expires, the UE initiates a re-registration process to update the registration data and registration state of the user in the IMS network, so that the user can continue to perform the service process.
In the prior art, the UE initiates the registration request to the IMS network, and after the registration succeeds, the UE does not initiate the re-registration process in the registration period initiatively. If one of the network elements (for example, the P-CSCF, S-CSCF, or AS) storing the registration data of the user in the IMS network fails in this period, the registration data of the user on the network element will become invalid (for example, the registration data of the user is lost after one of the network elements is reset). At this time, if the UE initiates the service request, the network element will regard the UE as an unregistered one, and will reject the service request of the user. Therefore, the UE cannot perform a calling service in the registration period. In addition, when the user is called, as the registration data of the user on different network elements is different (some network elements store the registration data of the user, and the user is in the registered state, while other network elements do not store the registration data of the user), the called user cannot be located. Therefore, the corresponding called service cannot be performed either.
In conclusion, in the IMS network, if the registration data of the user becomes invalid because the network element storing the registration data of the user is abnormal, the user cannot perform the corresponding services in a registration period. In the existing standards, no mechanism for notifying the UE to initiate the re-registration under this situation is available.
In addition, in the prior art, if a network element fails, no corresponding service processing method is available to terminate the current service process, so the network service will remain in a stalled state, and the network service of the user cannot be recovered in time.
FIG. 3 is a detailed schematic structural view of the IMS network in the prior art. As shown in FIG. 3, the IMS network includes a CSCF and an HSS.
The CSCF provides a core control function in a core network, and is responsible for performing the registration authentication and session control of the UE, implementing the basic session routing functions for calling and called IMS users, routing and triggering value added services to the AS, and performing service control interaction when conditions are satisfied according to the IMS filtering rules subscribed to by the user.
The HSS is configured to store IMS subscription information set when an operator opens an account, and supports customization and modification of subscription data by the operator or end user through an interface with the service management system. The HSS registers the S-CSCF domain name routing information in the IMS registration process through a Cx interface based on the Diameter protocol between the HSS and the S-CSCF, and supports downloading the basic IMS subscription information to the S-CSCF through the Cx interface. The HSS selects the S-CSCF serving the user during the user registration through the Cx interface based on the Diameter protocol between the HSS and the I-CSCF, or provides the name of the S-CSCF providing service to the user currently to the I-CSCF, so that the I-CSCF can route the registration information or session to the correct S-CSCF. The HSS provides subscription data and a remote database access interface for service logic scripts to a value added service SIP AS or a Service Capability Server (SCS) in Open Service Architecture (OSA) through an Sh interface between the HSS and the SIP and between the HSS and the AS, and the HSS is responsible for transparent storage of AS value added service data of specific subscribers, but does not involve semantic interpretation.
The Subscription Location Function (SLF) is a user subscription location function, which has an address resolution mechanism. When a network operator places multiple independent and addressable HSSs, the mechanism enables the I-CSCF, S-CSCF, and the AS to find the address of the HSS where the subscription data for specific user identities is stored. The SLF may be collocated with the HSS physically.
The AS obtains or updates data related to services of the user and user state information through the Sh interface of the HSS, and the S-CSCF obtains subscription information of the user through the Cx interface between the HSS and S-CSCF.
In the IMS network, the UE can use the services provided by the IMS network after registration in the network. Meanwhile, the UE may select to subscribe to unregistered services, and when the UE is not registered in the network, the network can still provide unregistered services such as call forwarding and call recording. When the UE is registered in the network or when the user is a party of a terminating call, the S-CSCF and the HSS exchange authentication data and service data of the user through a Server-Assignment-Request/Server-Assignment-Answer (SAR/SAA) command pair.
The application scenario of the SAR/SAA is that the S-CSCF receives a registration request of the UE sent from the P-CSCF or receives a session establishment request INVITE message from the I-CSCF.
(1) The S-CSCF performs the following operation on the HSS through the SAR command:
assigning an S-CSCF to a public identity, or clearing a name of an S-CSCF assigned to one or multiple public identities;
requesting for downloading user information, including user data or charging information; and
changing a registration state of a public user (PU) identity related to the user.
Server Assignment Type has 11 values, and two of which are explained as follows.
NO_ASSIGNMENT(0) is configured to request user data from the HSS by the S-CSCF, without affecting the registration state of the user.
UNREGISTERED_USER(3) is configured to indicate the S-CSCF that an INVITE request for a terminating call to an unregistered user is received.
If the name of the S-CSCF in the SAR received by the HSS is inconsistent with the name of the S-CSCF stored in the HSS, the HSS does replace the original name of the S-CSCF with the new one, but returns an Experimental-Result-Code of DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED, indicating that the S-CSCF has been assigned to the user.
When the operation type in the SAR received by the HSS is an operation that is not allowed for the user in the current state, for example, when Server Assignment Type is UNREGISTERED_USER, it indicates that the S-CSCF receives an INVITE request for a terminating call to an unregistered IMS public user identity (IMPU). However, if the IMPU is registered in the HSS, at this time, the HSS returns an Experimental-Result-Code of DIAMETER_ERROR_IN_ASSIGNMENT_TYPE, indicating that the S-CSCF has been assigned to the user, and the current state of the user is that the operation is not allowed.
(2) The HSS returns to the S-CSCF through an SAA command the following:
processing result;
user data;
charging information; and
all IMS multimedia private user identities (IMPIs) of IMS subscription.
The HSS can download the user data and charging function address only when the operation type is NO_ASSIGNMENT, REGISTRATION, RE_REGISTRATION, or UNREGISTERED_USER.
Then, the process that the user initiates a terminating call or originating call, or the AS replaces the user to initiate an originating call service in the IMS network in the prior art will be described below.
FIG. 4 is a schematic view of the implementing process for a terminating call session that is not registered in the network of a user in the prior art. As shown in FIG. 4, the process includes the following steps.
In Step 4001, the I-CSCF receives an INVITE message for a terminating call to a certain user.
In Step 4002, the I-CSCF initiates a Location-Info-Request (LIR) message to obtain information about the S-CSCF serving the user or a capability set of the required S-CSCFs.
In Step 4003, if the HSS records the name of the S-CSCF serving the user, the HSS returns the name of the S-CSCF to the I-CSCF through a Location-Info-Answer message, and if the HSS does not have the record, the HSS returns the capability set of the S-CSCFs that meets the service requirements of the user.
In Step 4004, if the HSS does not return the name of the S-CSCF, but returns the capability set of the S-CSCF, the I-CSCF selects an appropriate S-CSCF according to the capability set of the S-CSCFs returned by the HSS.
In Step 4005, the I-CSCF forwards the INVITE request to the S-CSCF.
In Step 4006, if the S-CSCF does not have user data, the S-CSCF sends an SAR to the HSS to request the user data, and the Server Assignment Type parameter in the SAR command is set to UNREGISTERED_USER, so as to inform the HSS that the current state of the user is an unregistered terminating call.
In Step 4007, the HSS downloads the user data to the S-CSCF through an SAA.
In Step 4008, the S-CSCF performs service control according to the user data, and carries out subsequent processing.
FIG. 5 is a schematic view of the implementing process for a terminating call session that is registered in a network of a user in the prior art. Unlike the method shown in FIG. 4, the process shown in FIG. 5 does not include Step 4004, Step 4006, and Step 4007, because the user has been registered in the network, the network has assigned the S-CSCF serving the user, and the HSS stores the name of the S-CSCF; therefore, the process that the I-CSCF selects the S-CSCF according to the capability set of the S-CSCFs in Step 4004 will not occur here. In addition, the S-CSCF has downloaded the user data from the HSS when the user is registered, so the process that the S-CSCF downloads the user data from the HSS through the SAR/SAA in Step 4006 will not occur here either. Further, normally, the user state recorded in the HSS is registered, and the name of the related S-CSCF is stored in the HSS, so the situation that the S-CSCF does not have the user data will not occur, and Step 4007 does not need to be performed here.
FIG. 6 is a schematic view of the implementing process that the AS replaces the user to initiate an originating call session in the prior art. As shown in FIG. 6, when the AS replaces the user to initiate the originating call, the AS may obtain the name of the S-CSCF serving the user from the HSS through a third-party registration or through an Sh interface. If the AS obtains the name of the S-CSCF serving the user before replacing the user to initiate the originating call, Step 601a in FIG. 6 is performed, that is, the AS directly routes the session to the S-CSCF serving the user. If the name of the S-CSCF serving the user cannot be obtained, Step 601b1 needs to be performed.
In Step 601b1, the session is routed to the I-CSCF of the home domain of the user.
In Step 601b2, the I-CSCF initiates an LIR message to the HSS, fills a calling user identity in a P-Asserted-Identity header field of the message to the LIR, and adds an originating call request flag to query information about the current location of the user, that is, information about the S-CSCF serving the user.
In Step 601b3, the HSS queries information corresponding to the user in a database according to the user identity in the LIR, and returns the name of the S-CSCF serving the user or a capability set of the S-CSCFs to the I-CSCF through an LIA.
In Step 601b4, if the HSS returns the capability set of the S-CSCFs, the I-CSCF needs to select the S-CSCF according to the capability set.
In Step 601b5, the I-CSCF routes the INVITE message to the S-CSCF returned by the HSS, or to the S-CSCF selected for the user according to the capability set of the S-CSCFs returned by the HSS.
In Step 602, if the S-CSCF does not have information about the user, the S-CSCF carries the user identity in the P-Asserted-Identity header field in an SAR, so as to request the subscription data of the user from the HSS, and if the S-CSCF has the information about the user, Step 604 is performed directly.
In Step 603, the HSS returns the requested subscription data of the user to the S-CSCF through an SAA.
In Step 644, the S-CSCF performs the service control.
In Step 605, the S-CSCF carries out subsequent processing.
FIG. 7 is a schematic view of the implementing process that the user initiates an originating call session in the prior art. As shown in FIG. 7, the process includes the following steps.
In Step 701, the UE initiates an INVITE message, and may optionally fill a Public User Identity indicating the identity of the UE in a P-Preferred-Identity header field.
In Step 702, after receiving the INVITE message, the P-CSCF checks whether the message contains the P-Preferred-Identity header field, and checks whether the value of the header field matches a registered Public User Identity recorded in the P-CSCF, and if the value of the header field matches a registered Public User Identity recorded in the P-CSCF, the P-CSCF uses the Public User Identity as the initiator of the session, and fills the Public User Identity in the P-Asserted-Identity; if no matching registered Public User Identity is found, or the P-Preferred-Identity header field does not exist, the P-CSCF selects a default Public User Identity as the initiator of the session for the user, and fills the Public User Identity in the P-Asserted-Identity.
In Step 703, after receiving the INVITE message, the S-CSCF triggers services according to the identity of the calling user in the P-Asserted-Identity header field in the message, and routes the subsequent session according to the Request-URI (that is, the called user) in the INVITE message.
After careful analysis of the above processes, it can be seen that, in normal situations, that is, when the user state recorded in the HSS is registered and the name of the related S-CSCF is stored, the S-CSCF always has the user data. However, when the IMPU of a user is lost because of sudden abnormity of the S-CSCF that the user registers, for example, in the case of system breakdown and reboot, if the UE of the user does not register in this process, the subscription information of the user in the HSS is not updated, and the registered user is still recorded as being registered on the original S-CSCF.
At this time, when the S-CSCF receives the session request INVITE message sent by the I-CSCF or the AS, as the S-CSCF does not have the corresponding user data, the S-CSCF sends an SAR to the HSS to request for the user data, and the Server Assignment Type parameter in the SAR command is filled as UNREGISTERED_USER. However, the HSS finds that the S-CSCF initiating the SAR and the S-CSCF recorded in the HSS are the same, but the state of the IMPU of the user requesting for operation is registered in the HSS. At this time, the HSS will not return the service information of the user in the SAA, but set Experiment-Result-Code as DIAMETER_ERROR_IN_ASSIGNMENT_TYPE and return it to the S-CSCF, indicating that the S-CSCF has been assigned to the user, and the current registered state does not allow the operation type. That is, the HSS informs the S-CSCF that the IMPU is in the registered state in the HSS, so the unregistered operation is not allowed. The S-CSCF returns a failure response to the I-CSCF, and the session fails.
When the S-CSCF receives the originating call request INVITE message sent from the P-CSCF, and the S-SCCF does not have the user data of the IMPU contained in the P-Asserted-Identity because of the reboot, the S-CSCF will directly return a failure to the P-CSCF, and the session fails.
Therefore, in the prior art, in the case of system breakdown or similar events of the S-CSCF, if the IMPU registered in the S-CSCF is not re-registered, the S-CSCF cannot provide the terminating call, originating call initiated by the UE, or originating call initiated by the AS on behalf of the user to the user corresponding to the IMPU.